% Chapter Template

\chapter{Conoscenze apprese} % Main chapter title

\label{Chapter8} % Change X to a consecutive number; for referencing this chapter elsewhere, use \ref{ChapterX}

\lhead{Capitolo 8. \emph{Conoscenze apprese}} % Change X to a consecutive number; this is for the header on each page - perhaps a shortened title
%TODO pure questo dev'essere meno narrativo e più informale? I don't think so.
Ciò che abbiamo imparato in questo corso non riguarda solamente la materia proposta, infatti la più grande differenza rispetto ad ogni altro corso (riferito alla nostra esperienza personale) è data dalla fase di progettazione. Solitamente dato un certo obiettivo, il fine era solamente quello di costruirne un prototipo funzionante, non preoccupandosi eccessivamente della correttezza delle scelte, ma cercando di adattarle progredendo nello sviluppo; in questo caso invece, ci siamo trovati in una condizione nuova, in cui la parte di programmazione non viene preposta al resto, ma diventa secondaria alla progettazione e alla risoluzione concettuale delle problematiche. 
Questo approccio ha mostrato i suoi frutti appena è stato necessario mettere in pratica ed implementare le idee maturate durante la progettazione, infatti, tralasciando le problematiche intrinseche all’uso di un linguaggio per noi nuovo, non è stato necessario inventare soluzioni nuove, ma seguire il percorso costruito precedentemente. Questo ha comportato anche un numero considerevolmente inferiore di problemi causati da effetti collaterali di soluzioni non pensate adeguatamente, facilitando la fase di implementazione.
Un’altra cosa che riteniamo molto importante è ciò che il corso (ed il relativo progetto) ci ha insegnato riguardo alla concorrenza, e l’importanza di costruire un’architettura robusta in grado di mantenere un comportamento coerente anche con l’uso di più task e risorse condivise, cosa sicuramente non banale e che causa problemi ed errori difficilmente individuabili. Proprio riguardo questa parte è stato importante capire come la scelta del linguaggio non sia basata sulla semplicità di quest’ultimo, ma dipenda dall’utilizzo e dai vincoli necessari al funzionamento del programma: utilizzare Java al posto di Ada nelle situazioni critiche del core o del broker avrebbe reso complicato se non impossibile garantire la correttezza dell’esecuzione ed il suo determinismo logico, facilmente ottenibile tramite le entry e procedure di cui dispone Ada.
Altra cosa importante è ciò che abbiamo imparato riguardo la distribuzione, solitamente affrontata manualmente tramite socket o altri espedienti. In un sistema complesso risulta importante poter definire a priori l’architettura su cui si basa l’intero sistema, in modo da essere a conoscenza di ciò che accade tra ogni nodo. Per quanto nel nostro caso non sia stato utilizzato un middleware, bensì una libreria per lo scambio di messaggi, abbiamo comunque definito gli attori del nostro sistema durante la progettazione, ma come detto precedentemente abbiamo scelto di non legarci ad un altro software per mantenere la portabilità del codice, e quindi abbiamo optato per una soluzione che si pone in mezzo tra la rigidità del middleware e la flessibilità (e relativa fragilità) dell’implementazione manuale. 